Here is a list of items that you may encounter as you upgrade your Domino 8.5 XPages Application to 8.5.1;
JavaScript Context Changes.
Brief Description:
In Domino XPages 8.5, there was a bug in the JavaScript context which remained valid for the entire life cycle of a page. This means that every variable used by JavaScript expressions within the page remained valid between requests, until the page was discarded from memory. This meant that some temporary variables, used in computation, consumed memory while they were not needed anymore.
This behaviour has been changed in 8.5.1, which will probably break some existing applications.
Impact:
This is likely to break your application if it uses techniques similar to those used, or uses, the Discussion 85 template. This usually results in a runtime exception.
Solution:
We have provided an option that reverts this behavior explicitly. This is done through a new property:
# Discard the JavaScript context for a page after the page is processed
# This is a runtime optimization that is set to true by default but might be
# reverted to avoid compatibility issues (although it is *not* advised).
#xsp.persistence.discardjs=true
However this workaround isn't recommended. A good practice is to ensure that your application does not relying on this behavior.
If your application fails due to this change, it is best to update the application not to depend on the discarded variables, but it may be useful as a short term workaround to change the value of the property to false, either at the server level or within the application's xsp.properties file.
Here is an example of keeping data within the viewScope, which is map of properties for the current page:
<xp:this.beforePageLoad><![CDATA[#{javascript:
viewScope.responseCount = responseCount;
}}]]></xp:this.beforePageLoad>
And then further access to the member should be done like this:
<xp:this.rendered><![CDATA[#{javascript:viewScope.responseCount == 0}]]></xp:this.rendered>
Event Handler Changes:
Brief Description:
In 8.5.1 a new property has been added to the eventHandler (xp:eventHandler) control called 'script'. This enables the configuring of client simple actions that run on the browser. However, Designer 851 will regenerate client JavaScript that is associated and add this new property which will fail if this application is run on a Domino 85 server.
For example, the following client side alert in 8.5...
<xp:link escape="true" text="say Hi" id="link1">
<xp:eventHandler event="onclick" submit="false">
<xp:this.handlers>
<xp:handler type="text/javascript">
<xp:this.script>
<![CDATA[alert("Hi")]]>
</xp:this.script>
</xp:handler>
</xp:this.handlers>
</xp:eventHandler>
</xp:link>
...will in Designer 8.5.1 become ...
<xp:link escape="true" text="say Hi" id="link1">
<xp:eventHandler event="onclick" submit="false"
id="eventHandler1">
<xp:this.script>
<![CDATA[alert("Hi")]]>
</xp:this.script>
</xp:eventHandler>
</xp:link>
This won't cause a problem if you upgrade the Domino server to 8.5.1, but it will fail if the application remains on a 8.5 server.
Solution:
If you wish to continue using the application on 8.5 servers, you will have to manually change it back to the old format, and ensure you do not edit the script in the Events view. Do this though the Source pane.
Navigation can now be computed.
Brief Description:
The Navigation Rule tag was present in 8.5, but it has changed substantially in 8.5.1, so that an 8.5.1 Navigation Rule will not run on an 8.5 server. The implementation was changed so that the target XPage can be computed, related to the issue PHAN7U5K8C. The page version will change to 8.5.1 when any Navigation Rule is recompiled in 8.5.1, even though you have not changed the XPage. There is an advanced user workaround, but it is recommended to instead revert back to using an 8.5 Designer install.
Impact:
You will be adversely impacted if you open your Domino 8.5 XPages application in Domino Designer 8.5.1 and expect this application to still run on Domino 8.5.
Solution:
The best solution here is to avoid using Domino Designer 8.5.1 on Domino 8.5 applications that are on a Domino 8.5 server.
However, there is an advanced user workaround, but it is recommended to instead revert back to using an 8.5 Designer install. You can initialize the navigation rule in JavaScript code instead of in the compiled Java code, so that it will work on both an 8.5 and an 8.5.1 server.
If you open the .java file corresponding to the XPage, you'll see the code that creates and initializes the navigation rule. e.g. for this .xsp source:
<xp:this.navigationRules>
<xp:navigationRule outcome="xsp-success" viewId="/page2.xsp"></xp:navigationRule>
</xp:this.navigationRules>
In 8.5.1 you'll see something like:
UIViewRootEx2 result ...
...
NavigationRule navigationRules = new NavigationRule();
navigationRules.setComponent(result);
navigationRules.setViewId("/page2.xsp");
navigationRules.setOutcome("xsp-success");
result.addNavigationRule(navigationRules);
In 8.5 you'll see something like:
UIViewRootEx2 result ...
...
NavigationRule navigationRules = new NavigationRule();
navigationRules.setViewId("/page2.xsp");
navigationRules.setOutcome("xsp-success");
result.addNavigationRule(navigationRules);
(that is, it doesn't call setComponent).
Copy that code into the XPage Events view, the afterPageLoad event, convert the first line to JavaScript, conditionally call the setComponent method, and use "view" instead of "result", like so:
<xp:this.afterPageLoad><![CDATA[#{javascript:
var navigationRules = new com.ibm.xsp.application.NavigationRule();
if( navigationRules instanceof com.ibm.xsp.binding.ComponentBindingObject ){
navigationRules.setComponent(view);
}
navigationRules.setViewId("/page2.xsp");
navigationRules.setOutcome("xsp-success");
view.addNavigationRule(navigationRules);
}]]></xp:this.afterPageLoad>
Then remove the navigation rules from the XPage source, by deleting these lines:
<xp:this.navigationRules>
<xp:navigationRule outcome="xsp-success" viewId="/page2.xsp"></xp:navigationRule>
</xp:this.navigationRules>
The XPage will no longer be restricted to 8.5.1.
See also
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/XPagesPageVersions.htm
Using .getUrl():
Brief Description:
In Domino 8.5 the javascript engine automatically converted context.getUrl() to a string. This was an incorrect implementation and now in 8.5.1 an object of class XspUrl() is returned.
Impact:
Your 85 XPages application will fail on Domino 8.5.1 if it expects .getUrl() to return a string.
Solution:
The solution is easy. Instead of calling
context.getUrl().indexOf(...)
insert a toString() call:
context.getUrl().toString().indexOf(...)
Script Library and Function Names.
Brief Description:
In 8.5 you could give a function the same name as the Script Library name, e.g. log() function in log.jss. This has changed in 8.5.1 where this practice is no longer allowed.
Impact:
This is not a normal use case but if you do have function and script libraries the same name these calls will fail as the function call will first find the library and return the library global object.
Solution:
Rename function and script libraries if they have names and then re-factor the application where these names were previously used.
The Button's Icon Class
Brief Description:
Use of the Button iconStyleClass property has been deprecated. It will give a warning in the problems view when the application is opened in Designer 8.5.1. It will be ignored on the Domino 8.5.1 server, rather than giving an error message.
Impact:
Low impact though
Solution:
The solution is to update your application to use a dojoAttribute instead of that property.
This old button:
<xp:button value="Save" id="button1" dojoType="dijit.form.button"
iconStyleClass="greenClass">
</xp:button>
would be changed to
<xp:button value="Save" id="button1" dojoType="dijit.form.button">
<xp:this.dojoAttributes>
<xp:dojoAttribute name="iconClass" value="greenClass"></xp:dojoAttribute>
</xp:this.dojoAttributes>
</xp:button>
The changed application will no longer run on an 8.5 server, since the dojoAttributes property is new to 8.5.1.
Localization Changes.
Brief Description:
The Localization Options, in the Application Properties, has changed slightly. In 8.5, there is a check box "Do not modify Existing Properties Files". When not checked, any translations you had previously created will be overwritten. The existing property files are deleted and new copies are made containing the language code and the untranslated text from the source XPage.
In 851, this check box has been replaced with another, "Merge source file changes into property files". When this is checked, any translations you had previously created may be overwritten. This option is usually less destructive than the 8.5 option. It attempts to merge the changes to the XPages into the translated property files, so that if text is unchanged it will probably remain translated. Translated text that is now unused will be moved to comments at the top of the translated files. If moving existing applications from 8.5 to 8.5.1, it may match some translated text with the wrong untranslated source value, leading to inaccurate processing of the translated files. In that situation, you should import your backup copy of the translated property files and the corresponding old untranslated property files.
More information here -
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/UsingLocalizationOptions.htm
Impact:
Minimal to no adverse effects.
In 8.5.1, if the Merge option is disabled and you change the text in some XPage, you will get a warning in the Problems view, like so:
That warning indicates that the property file contents do not match the XPages. In that situation, the contents of the property files will not be used for the out of date values."[de| text ]" will be displayed, using the locale code and the text from the XPage. "[| text ]" is displayed when opening the page in the source language.
To detect this situation, the values in the XPage source are compared to the text in the main property file. It also occurs if you delete values from the translated property files.
Solution:
None needed
Hidden Input, 'New' Control
Brief Description:
The Input Hidden control was added in 8.5.1, but is marked as version 8.5, because the run time code for that control was present in the 8.5 server, just not made public.
Impact:
You will not encounter a problem running an XPage with an Input Hidden control on an 8.5 server. You will have a problem if you attempt to open such an XPage in an 8.5 Designer install, as it will complain that it is an unknown tag.
Solution:
None needed
...